1. Field of the Invention
The present invention relates to a data processing method that implements device control in an object-oriented operating system. The present invention also relates to a recording medium storing a program that implements the data processing method, as well as to a data processing apparatus incorporating the recording medium. Details of certain features of the present invention are described in European Patent Application No. 0.753,811 A1 entitled xe2x80x9cData processing method and devicexe2x80x9d and filed by the same assignee on Jul. 12, 1996 claiming a Convention Priority on JP 178625/95, filed Jul. 14, 1997, the complete disclosure of which is hereby incorporated herein by reference.
2. Description of the Related Art
In general, device drivers that are programs for controlling various hardware devices are implemented as part of an operating system, as illustrated in FIG. 8. More specifically, the operating system, in response to a request for using a certain device driver given by a client or to a hardware interrupt, retrieves a device driver table to find the target device driver complying with the request or the interrupt from among device drivers registered in the device driver table. The operating system then calls the found device driver by means of a function call and executes the called device driver.
The client""s request is given by means of a system call, while the hardware interrupt is made by invoking a kernel thread of the operating system.
This known system has the following problems.
(1) Adaptability of the operating system is limited and replacement of a device driver is not easy because the device driver is implemented as part of a kernel of the operating system.
(2) Any error in a device driver affects the whole operating system because the device driver is executed with the same authority as the kernel of the operating system.
(3) Interrupt and other controls are performed on independent device drivers. The programmers who form the device drivers, therefore, are required to have knowledge of the whole system and to consider the influence of each device driver on other parts of the system.
(4) The style of programming of the device driver is significantly different from that for application programs because the device driver is implemented as part of the kernel of the operating system. Therefore, it is not easy for a programmer to form a device driver unless he is familiar with and well trained in the programming style which is used in describing device drivers.
In order to overcome these problems, a method has been known in which device drivers are described by using an object-oriented technique. When the object-oriented technique is used, the device drivers are formed as parallel objects outside the operating system, in the same way as that for application programs, as shown in FIG. 9 by way of example.
The term xe2x80x9cparallel objectsxe2x80x9d is used in this specification to mean program functions in the form of object modules which are objective entities to be handled by the operating system. Thus, the parallel objects are the units to be handled or processed. For instance, scheduling by the operating system is performed on a parallel-object basis. Communication also is executed on the units of parallel objects. In other words, the objects constitute units for operations such as resource management and exclusive execution. The use of such objects enables a programmer to form an object without requiring knowledge of contents of other objects. Thus, the contents of each object can be determined without taking into account factors such as exclusive control.
The described method relying upon the object-oriented technique has the following two major features.
(1) A request from a client to a device driver is sent in the from of a message from the client to the device driver described as a parallel object, as indicated by xe2x80x9crequestxe2x80x9d in FIG. 9. Similarly, an interrupt request is sent, as indicated by xe2x80x9cinterruptxe2x80x9d in the FIG. 9, in the form of a message from the operating system to the device driver described as a parallel object.
(2) Each device driver runs with a single thread, and the control of the interrupt mask is performed on independent device drivers. Thus, when a device driver is operating, interrupts to be handled by this device driver are not accepted. This relieves the programmers from the burden of considering exclusive control and other controls to cope with an interrupt when they describe each device driver.
By virtue of the two major features set forth above, device drivers described as parallel objects can be formed in the same way as that for application programs. In addition, replacement of device drivers can easily be carried out because the device drivers are implemented outside the operating system. It is also to be appreciated that the stability of operation of the operating system is greatly improved because an error occurring in one device driver does not affect the entire operating system.
Thus, the described problems encountered with the device drivers implemented as part of an operating system in the manner shown in FIG. 8 can be overcome by the technique shown in FIG. 9 in which the device drivers are described as parallel objects similar to application programs.
The technique shown in FIG. 9, however, is still unsatisfactory in that a running device driver does not accept any interrupt. A concept termed as xe2x80x9cinterrupt maskxe2x80x9d is used to express the state of the device driver as to whether or not the device driver accepts an interrupt. For instance, the state of the device driver which rejects an interrupt is expressed as xe2x80x9cthe interrupt mask is closedxe2x80x9d. Thus, an expression xe2x80x9cinterrupt mask is openxe2x80x9d means that the device driver is in a state ready to accept the interrupt.
In the technique shown in FIG. 9, the interrupt mask is closed when the device driver is running. Consequently, interrupt latency is prolonged when the processing which is being executed by the device driver includes time-consuming work such as copying of data.
Thus, interrupts cannot be accepted when the device driver is running because each device driver runs with a single thread. Hitherto, the only solution to this problem was to shorten the method of each device driver. It has been therefore difficult to describe a device driver which poses a severe restriction of interrupt latency when describing the device drivers in the form of parallel objects.
Accordingly, an object of the present invention is to provide a data processing method based on object-oriented device drivers and capable of shortening interrupt latency without impairing the advantage offered by the use of the device drivers.
Another object of the invention is to provide a recording medium storing a program which implements the data processing method.
Still another object of the invention is to provide a data processing apparatus incorporating such a recording medium.
To these ends, according to one aspect of the present invention, there is provided a data processing method in which a device driver for driving a hardware device is described in terms of a multi-thread object capable of allocating a message processing thread and interrupt processing threads to be exclusively used for respective interrupts. The device driver assigns to the message processing thread a processing based on a message received by the device driver from another object thereby executing the processing in the message processing thread. When an event has occurred requesting an interrupt to the device driver, the device driver executes an interrupt processing corresponding to the event in a processing thread corresponding to the event, wherein, in case that the corresponding interrupt processing thread is busy due to execution of another interrupt processing in response to another interrupt when the event has occurred, the interrupt processing corresponding to the event is held without being executed regardless of the state of the message processing thread and is executed only after completion of the interrupt processing which is under execution in the corresponding interrupt processing thread.
For the purpose of achieving synchronization to enable an exclusive control as required in, for example, making access to common data, it is preferred that an order of priorities is set between processing in the message processing thread and processing in the interrupt processing thread. In case that a processing given a higher priority than the interrupt processing is being executed in the message processing thread when an interrupt is received by the device driver, execution of the interrupt processing corresponding to the received interrupt is delayed until the processing in the message processing thread is finished or until the setting of the priority order is changed so as to give higher priority to the interrupt processing than to the processing in the message processing thread. However, in case that the processing given the higher priority than the interrupt processing is not being executed in the message processing thread when the interrupt is received by the device driver, the interrupt processing is executed in the interrupt processing thread without delay after the receipt of the interrupt.
Preferably, an interrupt processing is divided into a plurality of portions having different levels of priority, and a portion of the interrupt processing of a higher priority is executed by being assigned to the interrupt processing thread while a portion of a lower priority is executed by being assigned to the message processing thread. This serves to shorten the time over which the interrupt processing is occupied, thus reducing interrupt latency.
In the data processing method of the invention as set forth above, each device driver is described as a multi-thread object. Therefore, any interrupt can be accepted by the interrupt processing thread even when a processing is under execution by the device driver, provided that such a processing has been assigned to and being executed in the message thread.
In accordance with another aspect of the present invention, there is provided a computer-readable recording medium storing a device driver which is a program for driving a hardware device. The device driver is described in terms of a multi-thread object capable of allocating a message processing thread and interrupt processing threads to be exclusively used for respective interrupt processings. The device driver assigns to the message processing thread a processing based on a message received by the device driver from another object thereby executing the processing in the message processing thread. When an event has occurred requesting an interrupt to the device driver, the device driver executes the interrupt processing corresponding to the event in a processing thread corresponding to the event, wherein, in case that the corresponding interrupt processing thread is busy due to execution of another interrupt processing in response to another interrupt when the event has occurred, the interrupt processing corresponding to the event is held without being executed regardless of the state of the message processing thread and is executed only after completion of the another interrupt processing in the corresponding interrupt processing thread.
Preferably, the device driver is arranged to allow setting of an order of priorities between processing in the message processing thread and processing in the interrupt processing thread. In case that a processing given a higher priority than the interrupt processing is being executed in the message processing thread when an interrupt is received by the device driver, execution of the interrupt processing corresponding to the received interrupt is delayed until the processing in the message processing thread is finished or until the setting of the priority order is changed so as to give higher priority to the interrupt processing than to the processing in the message processing thread, whereas, in case that the processing given the higher priority than the interrupt processing is not being executed in the message processing thread when the interrupt is received by the device driver, the interrupt processing is executed in the interrupt processing thread without delay after the receipt of the interrupt.
The device driver may divide an interrupt processing into a plurality of portions having different levels of priority. In such a case, a portion of the interrupt processing of a higher priority is executed by being assigned to the interrupt processing thread while a portion of a lower priority is executed by being assigned to the message processing thread.
In the recording medium of the invention as set forth above, each device driver is described as a multi-thread object. Therefore, any interrupt can be accepted by the interrupt processing thread even when a processing is under execution by the device driver, provided that such a processing has been assigned to and being executed in the message thread.
In accordance with still another aspect of the present invention, there is provided a data processing apparatus, comprising a recording medium storing a device driver which is a program for driving a hardware device and which is readable by the apparatus from the recording medium. The device driver is described in terms of a multi-thread object capable of allocating a message processing thread and at least one interrupt processing thread. The device driver assigns to the message processing thread a processing based on a message received by the device driver from another object thereby executing the processing in the message processing thread. When an event has occurred requesting an interrupt to the device driver, the device driver executes the interrupt processing corresponding to the event in a processing thread corresponding to the event, wherein, in case that the corresponding processing thread is busy due to execution of another interrupt processing in response to another interrupt when the event has occurred, the interrupt processing corresponding to the event is held without being executed regardless of the state of the message processing thread, and is executed only after completion of the interrupt processing in the corresponding interrupt processing thread.
Preferably, the device driver is arranged to allow setting of an order of priorities between processing in the message processing thread and processing in the interrupt processing thread. In case that a processing given a higher priority than the interrupt processing is being executed in the message processing thread when an interrupt is received by the device driver, execution of the interrupt processing corresponding to the received interrupt is delayed until the processing in the message processing thread is finished or until the setting of the priority order is changed so as to give higher priority to the interrupt processing than to the processing in the message processing thread, whereas, in case that the processing given the higher priority than the interrupt processing is not being executed in the message processing thread when the interrupt is received by the device driver, the interrupt processing is executed in the interrupt processing thread without delay after the receipt of the interrupt.
The device driver may divide an interrupt processing into a plurality of portions having different levels of priority. In such a case, a portion of the interrupt processing of a higher priority is executed by being assigned to the interrupt processing thread while a portion of a lower priority is executed by being assigned to the message processing thread.
In the data processing apparatus of the invention as set forth above, each device driver is described as a multi-thread object. Therefore, any interrupt can be accepted by the interrupt processing thread even when a processing is under execution by the device driver, provided that such a processing has been assigned to and being executed in the message thread.
These and other objects, features and advantages of the present invention will become apparent from the following description of a preferred embodiment.